If you've been following my more personal and/or general purpose blog at LiveJournal, you know that I've started to work for a company as a grunt PHP 5 programmer. Not only that, but I had also contributed to a volunteer project (not open-source at the moment, just not exactly for pay) for a friend which is written in PHP 4.
There is enough antagonism against PHP in the Perl world and elsewhere, so I'm not going to add a lot of one-sided anti-PHP criticism here. Instead, I'm going to say some good things and bad things about it.
First of all, I'm not entirely sure why my company's code is written in PHP to begin with instead of Perl, Python, Ruby or whatever. We run our application on a dedicated server (and on the developers' servers), and it's not supposed to be deployed elsewhere. My best bet so far was that the original programmers either only knew PHP well or liked it better than Perl. In any case, we now have a large body of code that is written in PHP, which will be time-consuming to re-implement from scratch in a different technology. I'm not saying it shouldn't be done, (Joel on Software put aside), I'm just saying it will be very costy.
At the moment, we're in the midst of converting the old code to Symfony, which is a PHP web development framework similar to Ruby-on-Rails (or Jifty or whatever), but not quite. My impressions of Symfony at the moment are positive. It has excellent documentation and examples, is very easy to setup, and is easy to learn and hack on. Some of which are more than I can say about Ruby-on-Rails, for example. In any case, Symfony is probably better for most big Model-View-Controller tasks than using plain PHP scripts.
Symfony has its own Object-Relational-Mapping called Propel. It's not bad, but some tasks are impossible to do using it without resorting to raw SQL. For example, it is impossible to set a column to the value of an SQL function. (e.g: "UPDATE mytable SET time=now() WHERE id = 5"). I'm not sure it can be done in Perl's Class::DBI either, though, but maybe in more sophisticated ORM's. (Note: I haven't tried or looked into DBIx::Class, yet).
Now for some observations about PHP:
PHP 5 has an interesting object system, which I was somewhat disappointed from. It supports only single-inheritance, and I'm not sure one can add methods to existing classes after the classes were declared like Smalltalk or Ruby (or even Perl 5 albeit it is not a common practice there.).
Plus, the PHP 5 object system has this public/private/protected mechanism for limiting the accessibility of methods or variables. Being used to Perl 5, I've made everything public until now, but then my conscience started to hurt, and I wondered whether I should make some things protected or (<gusp />) private.
When I worked with C++ I made everything either protected or public and disliked private because I could not access it from derived classes. But I still tend to see such "software engineering" language features as generally unnecessary (or at least don't miss them when doing object oriented Perl), and I wonder whether the PHP 5 people put it there to make it more Enterprisey. Does Perl 6 has something like that, BTW?
At the moment, I still find writing Perl code more natural than writing PHP code, where I have to consult a lot of functions and their manuals, and often get things wrong. I was especially dismayed to discover that the associativity of the ?: operator there was different from Perl or C. All of this slows me down quite considerably, but I believe my productivity is still pretty good.
This may partially explain why employers prefer employees with a lot of experience in a certain technology, because their coding is more fluent. (It's definitely not the only reason.)
I still haven't find a good way to debug my scripts except by using prints echo's or logs statements. I found a certain server-side debugger (even with PHP Eclipse integration) but did not get to set it up, and it interferes with eAccelerator.
Despite everything I am still able to produce code I'm happy with and which I find to be nice, modular and clean. So it's not impossible to write good or readable code in PHP (just as it's not impossible to write good or readable code in Perl 5, which people spread FUD about). My style of using PHP is different because of some of its limitations or dark corners I'm not familiar with. For example, I'm using a lot of loops instead of the Perl pipeline.
PHP has some good quoting and interpolation mechanisms: it has double quotes and single quoted strings (not q{ ... } and qq{ .... } and friends, though), and it has here documents. Interpolation of variables works nicely most of the time. All of these are more than I can say about Python, whose excuse for interpolation is the sprintf()-like (and sprintf-replacing) "%" operator.
PCRE Regular Expression should be placed delimited by "/"'s or a different delimiters inside strings. Like "/hello *world/". This is so the modifiers can be placed at the end without introducing extra syntax to the core language.
I still like the Perl 5 syntax better and the Perl 6 syntax and conventions admittedly makes even more sense.
One thing PHP got right, was not in the language, that sort of evolved but still isn't quite right, but in the implementation and standard built in library. PHP has a good common denominator where one can easily easily deploy and install scripts and even complex web applications on various limited hostings and expect them to work. While this is less of an issue if you have a shell account with a lot of space (and hopefully an admin you can contact about installing more modules) or your own virtual server, (or better yet, a dedicated server), it still makes deploying PHP applications in variable environments much easier.
I understand the perl5 maintainers' motivation for trying to keep the core as limited as possible while expecting it to be complemented by the CPAN and the various third party perl5 distributions. It's a trade-off, but it is still an advantage for PHP from this specific aspect.
I was gonna rant on a certain badly written code I found in our codebase, and then refactored to be more Perl-like, but it's getting late, so I may delay it to later on (and possibly ask permission for my supervisor). If you're interested to read more about my PHP experiences you can read my LiveJournal blog. I'm trying the relevant entries using my entries using my php tag but I may forget to add it right away. Plus, some of my posts contain several different topics.
I wonder how big a discussion this post will start. Even if you do have something to say remember: 1. Be civil and informative. 2. The burden of proof is on the one who makes the claim. 3. Avoid making logical fallacies and especially try to avoid the Ad hominem fallacy. Have fun Bashing PHP and PHPing Bash!
